This invention relates to the field of software accessibility testing. In particular, the invention relates to software accessibility testing using visual output.
Accessibility refers to the practice of making products (such as software, web sites, etc.) usable by people of all abilities and disabilities.
A screen reader is a software application that attempts to identify and interpret what is being displayed on a screen and re-presents the output to a user using audio output, or a Braille output device. This is useful to users who are blind, visually impaired, illiterate, or have learning disabilities.
One of the difficulties in accessibility testing of a product is reluctance or lack of training on the part of (able) testers to do the testing in a way that truly reflects the target user and their disability. This is specifically true for users who are unable to see visual aspects of the user interface and rely solely on screen reader technologies for feedback. To do such testing fairly and thoroughly the tester should only be listening via screen reader technology and operating the user interface with a keyboard. Unfortunately, sighted testers inevitably fall back to using their sight to read the graphical user interface and the mouse to interact with the user interface, so the standard of testing can be diminished.
Although provision of audio feedback and keyboard navigation broadens the target user base for the software, it can be a daunting task for a sighted tester to operate the user interface in this way. A blind person tends to be an expert user of the keyboard as a navigation tool, and generally can process audio from screen readers at a faster rate than sighted users. However, blind users are a scarce resource within a software organization (and those that are blind may not want to focus on accessibility testing) and so the accessibility testers are often people non-representative of this user group.
The current approach to accessibility testing is insufficient and prone to inconsistency in quality, where sighted testers lapse to their familiar graphical user feedback and mouse input device. This approach entails the (sighted) tester operating the user interface using only a screen reader and keyboard and attempting to complete a number of scenarios. Such an approach tends to result in (sighted) testers still looking at the user interface for a good portion of their testing, which runs the risk of them interpreting a visual cue that is not available to the unsighted target user.